Communication interface between PC&#39;s and auxiliary platforms in an intelligent network

ABSTRACT

This invention relates to user access device to intelligent services of an intelligent network (IN) comprising a service control point ( 2 ) that communicates with at least one group of physical entities ( 4, 6, 8 ) designed to provide at least one initial service element, and with several auxiliary platforms ( 10   i ) designed to provide users with additional service elements for completing the initial service element. 
     According to the invention, the device also comprises a communication interface ( 12 ) that allows an auxiliary platform ( 10   i ) to send the service control point ( 2 ) service element execution queries in real time, and receive the data for executing these additional services from this service control point ( 2 ) as a response.

This invention relates to a user access device to IN (intelligentnetwork) services and method comprising a service control point thatcommunicates with at least one group of physical entities designed toensure at least one initial service element, and with several auxiliaryplatforms designed to provide the user with additional service elementsfor completing the initial service element.

Intelligent networks comply with ITU-T recommendations Q.120x, Q121x,Q.122x and Q.123x and stem from the need to provide access to servicesthat invoke several applications such as voice, electronic messaging,file transfer, or transactional processing, etc. services, bycentralising their control. Generally, applications are linked toperform a new service by using the architecture implemented in theapplication layer.

To allow the existing infrastructure in the communication network totake on the functionalities of the new service, intelligent networksimplement the following standardised functional entities:

-   -   Service Control Function (SCF), whose corresponding physical        entity in the IN network architecture is a Service Control Point        (SCP);    -   Service Switching Function (SSF), whose corresponding physical        entity is a Service Switching Point (SSP);    -   Service Data Function (SDF), whose corresponding physical entity        is a Service Data Point (SDP);    -   Specialised Resource Function (SRF), whose corresponding        physical entity is an Intelligent Peripheral (IP).    -   Service Management Function (SMF), whose corresponding physical        entity is a Service Management Point (SMP).

In known IN services, the Service Control Function (SCF) supports a userinterface that implements an important part of the Service ControlFunction (SCF). This user interface ensures:

-   -   all the actions implemented by the service to inform users and        prompt them to make their choices;    -   all the actions of the device that collect the user's choices;    -   release and concatenation of these actions such as invitations        and collection of choices;    -   concatenation of these actions with other service call        processing actions.

FIG. 1 provides a diagram illustrating a known device for accessing anNI service in which a service control point 2 communicates with aservice database 4, an access switch 6 to which the user telephone line7 is connected, a service management point 8, and several auxiliaryplatforms 10 _(i). An auxiliary platform 10 _(i) can be either anintelligent peripheral containing specific resources to allow adaptingservice controls on user demand, or a value-added server such as amessaging server, a service management point informing users of theirconsumption or any other type of server. The auxiliary platform can alsobe another service control point when two intelligent networks areconnected within the same call.

The resources of an intelligent peripheral can be announcers, speechsynthesis equipment, speech recognition equipment, equipment requiredfor videoconferencing, tone generators, speech synthesis tests orprotocol converters, etc.

When an auxiliary platform is an intelligent peripheral, two situationsmay arise:

-   -   the service control point 2 manages all the service control        functions, for example, in a card service in which the service        control point 2 manages the launching of the card and code digit        input phase, the launching of the authentication based on the        digits entered, the verification of the card's rights, the        launching of the requested number entered, the verification of        the rights that the card has to call this number, the number        call, as well as the concatenation with the next call.    -   the service control point 2 assigns certain subtasks to the        intelligent peripheral, in lesser or greater numbers depending        on whether the intelligent peripheral is used in “step” or        “script” mode.

In “step” mode, the intelligent peripheral is completely controlled bythe service control point 2 that, during an initial command, instructsit to, for example, transmit a specific message to a user, and inanother command, collect the user's choice.

In “script” mode, the intelligent peripheral has some latitude inconcatenating certain user interface subtasks such as the transmissionof an invitation message, collection of the user's choice andtransmission of another invitation message.

In both cases, the intelligent peripheral performs the requested taskand recognises the service control point 2 without everself-concatenating the tasks it has been assigned. Moreover, theintelligent peripheral never concatenates user interface phases withother IN service phases. It is only used as an additional servicecontrol module 2 resource to ensure specialised functions, which areoften voice functions.

This centralization of the service control function (SCF) at the servicecontrol point 2 does prevent the user interface from developing quickly.Indeed, the part of the user interface functionalities that resides inthe service control point 2 and used to configure, launch, andconcatenate the tasks requested from the intelligent peripheral is oftenembedded in a monolithic software application that covers all callprocessing. Therefore, any modification in user interface functionalityrequires modification of the service control module 2, at the level ofdata transmitted to the intelligent peripheral for executing the tasksit has been assigned, at the phase concatenation level, and on theintelligent peripheral in order to modify the subtasks and the type ofdata to be received from the service control module 2. This results in alack of flexibility in the development of the service because of theneed to perform non-regression tests as soon as a modification is madeon the service control point 2 software application. This prolongs thedevelopment/validation cycles.

Furthermore, when an auxiliary platform is a value-added server, thereare no ITU-T recommendations or international standards governingexchanges. Moreover, operators have their own specifications that aresometimes slightly different from the standards.

When an auxiliary platform is a second service control point, there isno data exchange mode between these two service control points managingvarious services in two different intelligent networks.

This leads to a heterogeneity of communication interfaces between thevarious auxiliary platforms and the service control module, whichresults in the need to store the service control point 2 of severaldifferent software applications in the random access memory, making theservice control point more complex and hindering service development.

The object of the invention is to provide new distribution of servicecontrol functions between the service control point and the auxiliaryplatforms in which the IN service user interface is transferred over toexternal platforms, which are specialised machines that can concatenateall the user interface stages, while not being interface tributarieswith other equipment in the intelligent network.

Another goal of the invention is to eliminate the heterogeneity ofinterfaces between the service control module and the various auxiliaryplatforms in order to allow services to evolve without modifying thefunctions dedicated to the service control point.

According to the invention, the access device comprises a communicationinterface that allows an auxiliary platform to send the service controlpoint service element execution queries in real time, and receive datathat allows executing additional services from this service controlpoint, as a response.

According to the invention, for a given service, the queries sent to theservice control point have the same format, regardless of thetransmitting auxiliary platform, and the data sent by the servicecontrol point to the transmitting auxiliary platform have the sameformat.

According to the invention, the first service element that the auxiliaryplatform requests from the service control point is a userauthentication, access authorisation or a number call.

Thanks to the invention, the service control point SCP is relieved frommanaging additional services, which is transferred over to the auxiliaryplatforms. Therefore, the development of a new service variant does notinvolve modifying the service control point if this development onlyapplies to the user interface or additional services. Developments ofservice variants are therefore easier, since they are more common onexternal platforms than on the service control point.

Moreover, the cycle times of service developments are reduced in thesense that it is no longer necessary to perform non-regression tests onthe aspects, network, control, charging, etc. of the NI service becausethey remain under the control of the SCP, and only the auxiliaryplatforms evolve with the user interface or the additional services.

Furthermore, the genericity of the communication interface queriesaccording to the invention allow taking into account the various typesof auxiliary platform and, in particular, to solve the problem ofinteroperation of the intelligent network services when the auxiliaryplatform is a SCP of another NI.

The user access procedure to the NI service includes the followingstages:

-   -   real-time sending by the auxiliary platform to the service        control point of at least one execution query of a first service        element dedicated to the service control;    -   sending by the service control point to the transmitting        auxiliary platform of the data query that allows the latter to        execute additional services.

Other characteristics and benefits of the invention will be provided inthe description to follow, to be taken as a non-limiting example andreferencing the attached figures in which:

FIG. 1 provides a diagram partially illustrating the links betweenfunctional entities of a prior art intelligent network:

FIG. 2 provides a diagram partially illustrating the links betweenfunctional entities of an intelligent network according to theinvention.

FIG. 3 provides a diagram illustrating an initial mode of communicationbetween an auxiliary platform and a service control point according tothe invention;

FIG. 4 provides a diagram illustrating a second mode of communicationbetween an auxiliary platform and a service control point according tothe invention;

FIGS. 5 to 12 and 15 and 16 represent tables that illustrate the formatsof the data exchanged between a service control point and an auxiliaryplatform in a specific application according to the invention.

FIGS. 13 and 14 illustrate the concatenation of two servicesimplementing the procedure according to the invention.

FIG. 1 described above, illustrates a device for accessing an IN servicein which a service control point 2 communicates with a service database4, an access switch 6 to which a user telephone line 7 is connected, aservice management point 8 and several auxiliary platforms 10.sub.i. Anauxiliary platform indiscriminately designs an intelligent peripheral10.sub.1, 10.sub.2, a value-added server 10.sub.3 such as avoice-messaging server, a voice interactive server or a second INservice control point.

According to the essential characteristic of the invention, illustratedby FIG. 2, a communication interface 12, fitted between service controlpoint 2 and the auxiliary platforms 10 _(i), allows an auxiliaryplatform 10 _(i) to send the service control point 2 an initial serviceelement execution query in real time. This initial service element canbe user authentication, access authorisation or the number call. Theservice control point 2 executes this initial service element andresends data in response to the query sent to allow the transmittingauxiliary platform 10 _(i) to execute its dedicated additional services.The auxiliary platform then transmits other queries to the SCP so thatthe latter can execute its dedicated service elements.

Query transmission can be done through a direct link, such as the oneillustrated in FIG. 3, via TCP/IP (Transmission communicationprotocol/Internet protocol) or the SS7 (Signalling System N°7) protocol,or through a relay link, such as the one illustrated in FIG. 4, usingthe same path as the related speech circuit. In this case, becausequeries are transported in the speech path signalling, the platform caneasily create the link between the application queries and voicecommunication. This is not the case with a direct link because bothlinks are initialised, the first link to carry the queries over the IP(Internet Protocol) network or over the SS7 network, and the second linkto carry the speech signals. Therefore, it is necessary for theauxiliary platform 10 _(i) and the service control point 2 tosynchronise the two links. The mechanism used for this synchronizationis based on the use of a reference and is illustrated in FIG. 3 in thecase of an IP link. This mechanism is the same for a direct link via theSS7 protocol.

With reference to FIG. 3, the sequencing of the TCP/IP link using thereference is as follows:

-   -   I The service control point 2 launches a voice call via the        access switch 6 to a platform 10 _(i). An “R” reference is        placed in the signalling that sets up this call, for example,        National ISDN User Part (ISUP) signalling. This “R” reference        comprises the reference for the future exchange session for        auxiliary platform/service control point 2 application queries.    -   II The voice call arrives at the platform that reads in the        speech path signalling the “R” reference of the session of        queries exchanged with the service control point 2.    -   III The platform transmits an initialization query containing        the “R” reference over the TCP/IP link.    -   IV Using the “R” reference, the service control point 2 creates        the link between the call being sent to the platform 10 _(i)        over the speech path and the initialization query, and responds        to the initialization query by transmitting the response to this        initialization query to the platform 10 _(i) over the TCP/IP        link; this response also contains the “R” reference so that the        platform 10 _(i) can identify the voice call to which this        response is related.    -   V The platform 10 _(i) transmits other application queries over        the TCP/IP link according to the service that it initialises,        for example, an authentication request.

Whatever query is transmitted over the TCP/IP link, it contains the “R”reference; the response transmitted by the SCP over the TCP/IP link alsocontains this “R” reference. Also, during the entire query exchangesession over the TCP/IP link, the platform 10 _(i) and the servicecontrol point 2 can join the query session to the voice call.

In the case of a relay link, the sequencing is the same as in the caseof a link over TCP/IP, except that the reference is not useful becausenetwork signalling naturally creates the link between these queries andthe speech path on which the queries are based. The two streams in factfollow the same channel.

Sequences I to V correspond to their equivalents in TCP/IP modeillustrated in FIG. 3.

To better highlight the parameters exchanged between an auxiliaryplatform 10 _(i) and the service control point 2, a specific applicationwill be described in which the intelligent service is a Cardtelecommunications service. The service control point 2 will bedesignated in the next phase using the SCP-Card expression, andauxiliary platforms 10 _(i) will be external servers designated by theSE expression.

In terms of operation, the SCP-Card responds to the initialization queryof the dialogue between the Card Application and the application thatresides in the auxiliary platform 10 _(i) by sending an initialisationrequest with the following structure:

-   -   R-Initialisation_PCS={Contexte_A, Contexte_B}    -   Contexte_A={CtxDial, CtxSrv, CtxDdr, CtxCarte, CtxInfo}

-   Contexte_B={BufferSE}

FIG. 5 includes a table that explains the CtxDial parameter representingthe data that identifies the dialogue.

The Version field allows simultaneously managing two versions of thequery description: a new version N and the previous version N-1. Itindicates to the auxiliary platform 10 _(i) the version in which thequeries will be transmitted up to the end of the SCP-SE dialogue.

The service number in the application will be taken from the IdSvservice identifier by the auxiliary platform 10 _(i) application, ifrequired.

If the SCP-Card connects to an auxiliary platform 10 _(i) to initiate avoice dialogue over this auxiliary platform 10 _(i), the CodeReprisefield is absent.

If the SCP-Card reconnects to an auxiliary platform 10 _(i) to resumeand track a voice dialogue, the EntréeDialSE field increases in value asfollows:

EntréeDialSE=0 if the auxiliary platform 10 _(i) is recontacted afterthe calling party enters “*” during the call return. This is not takeninto account for services using voice recognition.

EntréeDialSE=1 if the auxiliary platform 10 _(i) is recontacted after ano answer by the called party.

-   -   EntréeDialSE=2 if the auxiliary platform 10 _(i) is recontacted        after the called party hangs up (call concatenation).

FIG. 6 includes a table that explains the CtxSrv parameter thatrepresents the service data over the Card call.

The NEnch parameter indicates the number of call concatenations thecalling party performs on the SCP-Card before connecting to theauxiliary platform 10 _(i) or between connections to different auxiliaryplatforms 10 _(i). The number of call concatenations is accumulated fromthe start of the Card call.

NRDeMax is the maximum number of called party call renewals authorisedby the SCP-Card.

FIG. 7 includes a table that explains the CtxDdr parameter thatrepresents the data over a calling line and the calling party.

The values for TypeTerm, CgPCateg, NatDdr, NResDdr, and PrefFD increasestarting from the Provide at the beginning of the Card call and byanalyzing the calling party number.

FIG. 8 includes a table that illustrates the CtxCarte parameter thatrepresents part of the data sent to the authentication centre AC and itsresponse.

These parameters can only be provided when the code-card input and theAuthentication Centre query are performed by the SCP-Card beforeconnecting to the auxiliary platform 10 _(i).

The value of Ipas increases upon inputting the subscriber card number orthe response sent by the authentication centre AC in the case of fastauthentication.

The remaining fields can be completed using the values provided by theAuthentication Centre (AC).

Note that the Code field representing the subscriber confidential codewill only be transmitted to the auxiliary platform 10 _(i) underexceptional circumstances for example, in an auxiliary platform 10 _(i)application that allows subscribers to modify their confidential code.

FIG. 9 provides a table explaining the CtxInfo parameter that representsadditional data.

The NumDdé parameter is useful if the auxiliary platform 10 _(i) is avoice messaging system that offers differed call service.

The TransMV field is also designed for a voice messaging type auxiliaryplatform and allows specifying the cause of the retransmission towardthis messaging system if needed: no answer, busy, congestion, during acalled party call.

MaxCom represents the maximum authorised communication duration,calculated in seconds by the Rate Server (RS) that resides in theservice management point. This field can only be completed if therequested number has been input and a query of the service managementpoint 8 has been performed by the PCS-Card before the connection requestto the auxiliary platform 10 _(i).

The RefAppel field is a sequence of 15 octets that breaks down asfollows:

-   -   octets 1 to 5: DATE field=start of call processing, DCB-coded in        the following format: MMDDhhmmss.    -   octets 6 to 7: CPAYS fields=SCP country code (DCB-coded).    -   octets 8 to 11: IDPCS field=SCP identifier (SGTQS code),        ASCII-coded without parity.    -   octets 12 to 15: REFC field=circular reference,        hexadecimal-coded.

The maximum length of the CaracServ field is 16 octets:

-   -   octet 1: CARSRV field=characteristic parameters of the        Intelligent Network services. It is coded on an octet in the        following manner (where A is the low-order bit):

A=1, rerouting not allowed (i.e., Audiotel or Toll Free). Else A=0.

B=1, Call Completion not allowed (i.e., 12). Else B=0.

C=1, AOCD (requested telephone charge). Else C=0.

D=1, parsing is not allowed without transmitting the response signal.Else D=0.

E, F, G, H on standby and set to =0.

-   -   octet 2: SVTR field=crossed services, value increase to 0Fh.

The Contexte_B field is used at the service control point to pass thedata previously transmitted by the auxiliary platform.

This field is useful when the service control point and the auxiliaryplatform recover a dialogue after it has been interrupted, for example,during call concatenation. The service control point does not interpretthe field that contains the data belonging to the auxiliary platform, asdoes the indication of a recovery point in its service script. Note thatwhen recovering dialogue for call concatenation, the auxiliary platformcan be the same type of platform as the one used previously, but must bea different sample.

Each time that the SCP-Card wants to completely release the connectionto the auxiliary platform 10 _(i), it first transmits a Release SCPquery to the auxiliary platform. The purpose of this query it to allowthe auxiliary platform 10 _(i) to release its own resources and be ableto transmit, in this particular case, a notification to the callingparty before the SCP-Card cuts off the link. Therefore, the SCP-Cardwill always wait for the response to the Release SCP to the auxiliaryplatform 10 _(i), or possibly, the timeout of no-answer to this query,before transmitting the FREE operation on the auxiliary platform link.

FIG. 10 indicates a table illustrating the card of parameters sent tothe auxiliary platform 10 _(i) in a Release SCP query to the auxiliaryplatform.

For some end-of-dialogues causes, the auxiliary platform 10 _(i) willnot be able to transmit voice messages to the calling party. Forexample, if the Release SCP query to the auxiliary platform is sentafter a number call request and hang-up request, the SCP-Card mustimmediately cut the calling party-auxiliary platform 10 _(i) voicecircuit (SPLIT) to establish the calling party-called party voicecircuit (JOIN). The list of CFDial codes therefore distinguishes thesituations where the auxiliary platform 10 _(i) may or may not have avoice link with the calling party until it sends its response:

CFDial=0 to 49: the auxiliary platform 10 _(i) does not have a voicelink with the calling party.

CFDial=50 to 255: the auxiliary platform 10 _(i) has a voice link withthe calling party up to the moment it transmits its response to theRelease SCP query to the auxiliary platform; it will therefore be ableto transmit a message to the calling party.

The CFDial codes≧100 designate the errors detected by the CardApplication Driver and sent to the application so that the latter canend the dialogue between the SCP-Card and the auxiliary platform 10 _(i)using a Release SCS to the auxiliary platform.

The SCP-Card continues its processing according to the cause of theCFDial dialogue end:

If CFDial=0: processing standby for called party response.

If CFDial=1: processing the communication follow-up with the calledparty.

Receipt of the auxiliary platform response awaited and processed in thecorresponding statuses.

For the other CFDial values, the SCP-Card awaits acknowledgement by theauxiliary platform 10 _(i) before launching a call end process. If theauxiliary platform 10 _(i) acknowledgement is not received, the SCP-Cardalso launches a call end process. In any case, receipt of the auxiliaryplatform 10 _(i) response allows the SCP-Card to release the link to theauxiliary platform 10 _(i) and increase the value of the communicationpart of the service it offers, the closing, if needed, and the sendingof a communication detail.

The SCP-Card transmission of an initialisation response is followed by aseries of application queries that the auxiliary platform transmits tothe SCP-Card. These are described below.

Of course, application processing of the SCP-Card upon receipt of thequeries from the auxiliary platform are given for information purposesfor the Card Application using the control interface according to theinvention.

If the query is an authentication request, an auxiliary platform 10 _(i)requests the authentication of a card-code from the card AuthenticationCentre via the SCP-Card. The acknowledgement of the card-code digits iscompletely dedicated to the auxiliary platform 10 _(i) that performs thefollowing tasks:

-   -   invitation to dial or say the numbers;    -   repetitions in case the user has not input or said the numbers:    -   possible format or length controls, etc.

Note that to query another Card Application Authentication Centre, thisrequest might need to be developed or specifications of otherauthentication queries might be needed because the types of dataresiding in these centres may vary from one application to another.

FIG. 11 represents a table that explains the parameters received fromthe auxiliary platform 10 _(i) for this authentication request.

Several types of authentication are possible on the SCP-Card. TheSCP-Card identifies these types of authentication using the card-codesequence format input by the user:

Format 1: low-grade authentication: “i digits” (i=9 card digits+4 codedigits).

Format 2: low-grade authentication after the set passes to DTMF: “#+i”or “*+i digits” (i=13).

Format 3: fast authentication: “j digits” (j=4 digits of the code only).

Format 4: fast authentication after the set passes to DTMF: “#+j digits”or “*+j digits” (j=4).

Format 5: high-grade authentication: “##+k digits” or “+#+k digits”(k=19 maximum).

The auxiliary platforms 10 _(i) have two possibilities:

-   -   the auxiliary platform 10 _(i) does not know the low-grade,        high-grade, or fast authentication notions, in which case, it        sends the SCP-Card a unique card-code sequence corresponding to        the raw information input or said by the user and concatenated        into a single sequence (Saisie_CC), even if the acquisition is        performed in several stages on the auxiliary platform 10 _(i).        The TypAuth field is therefore absent from the query.    -   the auxiliary platform 10 _(i) is aware of the four types of        authentication and is able to offer them to the user or identify        them when the user inputs/says them, in which case, the        auxiliary platform 10 _(i) sends the SCP-Card the concatenated        card number and the code number (Saisi_CC), without the “+”,        “#”, “##”, or “*#” identifiers, but with the type of        authentication recognised by the auxiliary platform 10 _(i)        TypAuth:

TypAuth=0: low-grade authentication (format 1 or 2).

TypAuth=1: fast authentication (format 3 or 4).

TypAuth=2: high-grade authentication (format 5).

In both cases, the SCP-Card does not receive the end delimiter if theinput is received in DTMF mode on the auxiliary platform 10 _(i).

FIG. 12 represents a table illustrating the parameters returned by theSCP-Card in response to this authentication request.

The CodeRetour parameter is common to all responses of the auxiliaryplatform queries to the SCP-Card. It comprises:

-   -   a Numéro field whose value is systematically 0 if the query was        processed correctly, and a positive value associated to the        error found, otherwise.    -   an Annonce field: contains the OSV announcement number that the        SCP would use if an error occurs, corresponding to the mode        without a control interface. This field is optional.    -   a FinAppel field: set to NO, it may allow the auxiliary platform        10 _(i) to continue its voice dialogue if the error does not        block its processing, and to repeat the query or concatenate a        new one (example: the authentication centre CRES indicates that        the code does not match). When set to YES, it indicates to the        auxiliary platform that the SCP-Card cannot continue the call.        The auxiliary platform 10 _(i) must inform the user of the error        and send a “Release auxiliary platform to SCP” query (example:        no answer from authentication centre without accepting the        reject exception).

The Ipas card number is systematically retransmitted to the auxiliaryplatform 10 _(i), whether it has performed the Saisi_CC sequenceanalysis or not.

The Code (user confidential code) field is only transmitted to theauxiliary platform under exceptional circumstances (example: auxiliaryplatform 10 _(i) application that allows a user to modify his or herconfidential code).

The Ilas, Tsc, Cco, Catc, Scom, Imi, and Cptx parameters are a copy ofthe parameters provided by the Authentication Centre. If the Card is notlimited, Cptx and Imi will be absent.

NbAuthMax and CptAuth allow the auxiliary platform 10 _(i) to modulateits card-code input announcements (first, nth, or last announcement), orto offer help after a specific failure rate.

Enchaînement_autorisé, Appel_urgent_Sans_crédit and Exception_rejet arederived by the SCP-Card from the type of authentication centre (AC)response and the call context. They are transmitted to the auxiliaryplatform 10 _(i) to direct the processing of its voice script.

When a query sent by the auxiliary platform 10 _(i) is an authorisationand service value increase request, the service term of the querydesignates not only an auxiliary platform 10 _(i) internal servicenumber, but also a requested number joined by the auxiliary platform 10_(i), as well as a number requested and joined by the SCP.

The authorization and service value increase request is sent by theauxiliary platform 10 _(i) to increase the value of the previouslyqueried service cost, authorise the user to consult the selectedsubsequent service and, if needed, open a new communication detail CDfor this service.

Query processing by the SCP-Card comprises three stages:

-   -   Value increase processing of the previous communication        (calculation of the duration, cost, CD transmission, decrease of        possible limit of the card).    -   Authorisation processing on the subsequent service (number        analysis, possible authorization/translation of a CD        transmission, SdT credit query).    -   Rate Application processing of the subsequent service (opening        of its CD).

The input parameters of the query (Valo, Aut, and ApTar) will indicatethe processing performed by the SCP-Card before sending the CodeRetour.

FIG. 13 illustrates an example in which a subscriber concatenates twointernal SV1 and Sv2 services over a single free access auxiliaryplatform 10 _(i) that includes the following stages:

a) Connection to the free access auxiliary platform 10 _(i). Nocommunication details (CD) are opened in the case of free access;

b) (Valo, Aut, ApTar)=(0, 1, 1). Authorisation request on service 1 andopening of communication detail CD1.

c) (Valo, Aut, ApTar)=(1, 0, 0). Value increase of communication detailCD1.

d) (Valo, Aut, ApTar)=(0, 1, 1). Authorisation request on service 2 andopening of communication detail (CD2).

e) (Valo, Aut, ApTar)=(1, 0, 0). Value increase of communication detailCD2.

FIG. 14 illustrates an example in which a subscriber concatenates twointernal SV1 and Sv2 services over a single paying access auxiliaryplatform 10 _(i) that includes the following stages:

a) When connecting to the auxiliary platform 10 _(i), the SCP opens acommunication detail DC0. The connection time to the auxiliary platform10 _(i) is counted from the moment the auxiliary platform 10 _(i) isoff-hook.

b) (Valo, Aut, ApTar)=(1, 1, 1). Value increase of communication detailDC0, authorisation request on service 1, and opening of CD1.

c) (Valo, Aut, ApTar)=(1, 1, 1). Value increase of communication detailDC1, authorisation request for the return to the general menu(essentially to determine the credit remaining of a limited card afterconsulting service 1), and opening of communication detail CD2.

d) (Valo, Aut, ApTar)=(1, 1, 1). Value increase of communication detailDC2, authorisation request on service 2, and opening of CD3.

e) (Valo, Aut, ApTar)=(1, 1, 1). Value increase of communication detailDC3, authorisation request for the return to the general menu, andopening of communication detail CD4.

f) (Valo, Aut, ApTar)=(1, 0, 0). Value increase of communication detailDC4.

Note that the time reference is always based on the SCP-Card clock. Thestart and end times of service queries must be saved by the SCP. Theauxiliary platform 10 _(i) must therefore formulate its authorisationand service value increase query according to the nature of the service(auxiliary platform 10 _(i) internal service, call joined by theauxiliary platform 10 _(i), or call joined by the SCP-Card) and indicateto the SCP when the time should be obtained. The input parametersinvolved are the triplet (Valo, Aut, ApTar) and theApplication_tarif_immédiate indicator:

In the case of an auxiliary platform 10 _(i) internal service (specificvoice menu of the auxiliary platform 10 _(i)), the auxiliary platform 10_(i) must increase the value of its authorisation and service valueincrease request with (Valo, Aut, ApTar)=(x,1,1) andApplication_tarif_immédiate=YES. The SCP saves the start time of theservice query just after the communication detail CD is opened. The endof the service query is indicated by a second query with (Valo, Aut,ApTar)=(1,x,x,).

In the case where the service is a call joined by the auxiliary platform10 _(i), the auxiliary platform 10 _(i) must increase the value of aninitial authorisation and service value increase request with (Valo,Aut, ApTar)=(x,1,0). The auxiliary platform 10 _(i) joins the call. Whenthe called party goes off-hook, it sends the SCP-Card a secondauthorisation and service value increase query with (Valo, Aut,ApTar)=(0,0,1) and the Application_tarif_immédiate=YES. When the userhangs up, the auxiliary platform 10 _(i) sends a third query with (Valo,Aut, ApTar)=(1,x,x,) to indicate the end of the conversation to theSCP-Card.

In the case where the service is a call joined by the SCP-Card: theauxiliary platform 10 _(i) must increase the value of an initialauthorisation and service value increase request with (Valo, Aut,ApTar)=(x,1,0). The SCP-Card recovers the conversation start and endtimes on the ANM/CON and REL signals without indication from theauxiliary platform 10 _(i).

FIG. 15 represents a table that illustrates the parameters received fromthe auxiliary platform 10 _(i) for this authorisation and service valueincrease query.

The ModeTax1 field is increased in value by the auxiliary platform 10_(i) according to the ModeTax2 parameter value of the previous servicevalue increase.

By way of example, a subscriber with a limited card chooses to query apaying service offered by the auxiliary platform 10 _(i). The lattersends the SCP-Card an authorisation and service value increase requestwith (Valo, Aut, ApTar)=(absent, present, present). The SCP-Cardperforms an SdT inquiry during the query processing to find the chargemethod applied to the service and communicates it to the auxiliaryplatform 10 _(i) in its response (ModeTax2). The auxiliary platform 10_(i) might not use this value during processing but it saves it untilthe user finishes querying the service. Once the query is completed, theauxiliary platform 10 _(i) sends the SCP-Card an authorisation andservice value increase request configured with (Valo, Aut,ApTar)=(present, absent, absent) by recalling the type of chargesapplied to the service in the ModeTax1 field. Thus, there is noconfusion for the SCP-Card regarding the service value increase mode.

-   -   ModeTax1 is equal to 0 (normal cost), 1 (inclusive cost), 2        (toll free), or 3 (ITX charges).    -   ModeTax1 is absent if Valo=0.

The Numéro field accepts all the available formats: national, short orlong distance unlocalised, special, international, abbreviated, orprivate.

The AnnCrédit=1 field allows the auxiliary platform 10 _(i) to requestthat the credit announcement be exceptionally transmitted by theSCP-Card in Voice Server Equipment (VSE) mode.

The Numéro and AnnCrédit fields are absent when Aut is absent.

The Application_tarif_immédiate field is absent when ApTar is absent.

In the case where the auxiliary platform query to a CARD-Card is anumber call request, it also takes into account the case of a routingrequest to an operator set after an input error occurs or when the userfails to input anything. The auxiliary platform 10 _(i) may precede thenumber call request with an authorisation service value increase queryon this number. For example:

-   -   for an ordinary requested number, the auxiliary platform 10 _(i)        would have performed an authorisation/service value increase        request on the called party number in order to verify the        minimum value that the number can have during routing.    -   for an operator set access number: the numbers are already        available in the operating data of the SCP-Card in network        format. They can be routed and used in the CREATE operation        without the SCP-Card needing additional analysis.

When the call return is distributed, the auxiliary platform 10 _(i) iscompletely released. Reconnection to the auxiliary platform 10 _(i) willbe performed in the following three circumstances:

-   -   when the calling party wishes to interrupt the call currently        being established;    -   when a timeout occurs due to a no answer from the called party;    -   or possibly, after the conversation to offer call concatenation.

The SCP-Card will indicate to the auxiliary platform 10 _(i) that therecovery point of the voice script is “enter asterisk,” “no answer fromcalled party,” or “call concatenation” using the value indicated in theContexte_A entréeDialSE field in the initialisation response.

FIG. 16 represents a table that illustrates the parameters received fromthe auxiliary platform 10 _(i).

The NumDdé field is optional and operates as follows:

-   -   NumDdé is absent if the auxiliary platform 10 _(i) has        previously transmitted an authorisation/service value increase        request. The SCP-Card has already saved the called party network        number (in the CREATE operation format) and its nature        (national, international, etc.) after having analysed the Numéro        field of the authorisation/service value increase request.    -   NumDdé is absent if the auxiliary platform 10 _(i) performs a        call request to an operator set. The Appel_opérateur field is        set to YES in this case.    -   NumDdé is directly a national network number that can be routed        if the auxiliary platform 10 _(i) wishes to establish        communication to a requested number without previous        authorisation/service value increase.

The RappelSE=0 field indicates to the SCP-Card that it must recontactthe auxiliary platform 10 _(i) after the called party has hung up. Ifthe RappelSE field is set to 1, the auxiliary platform is not recalledand the possible call concatenations will be offered in the withoutcontrol interfaces mode.

If the RappelSE field is set to 2, the auxiliary platform 10 _(i) is notrecalled and no call concatenation is offered in the without controlinterfaces mode.

Note that the CARD-Card does not implement any call concatenationwithout control interfaces (PCS/OSV mode) if the nature of the auxiliaryplatform 10 _(i) is that it can be called by the SCP in controlinterface mode when the SCP receives the Provide-Instructions command,because, in this case, the auxiliary platform 10 _(i) carries the entireuser interface of the service. In this example, RappelSE should never beequal to 1.

The Appel_opérateur field allows the SCP-Card to perform certainadditional processes specific to the retransmission to the operator:network operator number search in the operating tables, transmission ofan announcement to the operator once off-hook, etc.

Note that the Contexte_B field containing information that is useful tothe auxiliary platform 10 _(i) for recovering its voice script should besystematically transmitted to the SCP-Card with the number call querybecause, on each call, the auxiliary platform 10 _(i) cannot know ifthere will be “input asterisk” or “no answer from called party” typerecovery points.

On the other hand, the auxiliary platform 10 _(i) will still indicate tothe SCP if it wants to be recontacted or not after a successful callingparty-called party conversation by increasing the value of the inputparameter RappelSE field of a number call query.

1. User access device to intelligent services of an intelligent network(IN) comprising a service control point (2) that communicates with atleast one group of physical entities (4, 6, 8) designed to provide atleast one initial service element, and with several auxiliary platforms(10 _(i)) designed to provide the user with the additional serviceelements that complete the initial service element, device characterisedin that it also comprises a communication interface (12) that allows anauxiliary platform (10 _(i)) to send service element execution queriesto the service control point (2) in real time, and to receive data fromthis service control point (2) as a response that allows executingadditional services, wherein the auxiliary platform (10 _(i)) ensuresthe following additional services: a—user information when using theservice; b—user invitation to determine user choices; c—collection ofuser choices; d—activation and concatenation of actions (a), (b) and(c); e—concatenation of actions (a), (b) and (c) with other actions thatdo not stem from the platform but that are outsourced to the servicecontrol point (2) or to the physical entities (4, 6, 8) via the servicecontrol point (2), through service execution queries transmitted to theservice control point (2).
 2. Device according to claim 1, characterisedin that auxiliary platform (10 _(i)) is an intelligent peripheral. 3.Device according to claim 1, characterised in that auxiliary platform(10 _(i)) is a service control point of a second intelligent network. 4.Device according to claim 1, characterised in that the initial serviceelement execution query transmitted by the auxiliary platform is eithera user authentication request, an access authorisation request, or anumber call request.
 5. Device according to claim 1, characterised inthat the queries are sent to the service control point (2) in directmode according to the TCP/IP protocol.
 6. Device according to claim 1,characterised in that the queries are sent to the service control point(2) in direct mode according to the SS7 protocol.
 7. Device according toclaim 1, characterised in that the queries are sent to the servicecontrol point (2) in relay mode through the same channel that is usedfor voice signalling.
 8. Device according to claim 1, characterised inthat for a given service, the queries sent to the service control point(2) have the same format regardless of the transmitting auxiliaryplatform (10 _(i)), and the data sent by the service control point (2)to the auxiliary platform (10 _(i)) have the same format.
 9. Deviceaccording to claim 1, characterised in that the physical entity groupcomprises at least one access switch (6), and at least one servicemanagement point (8) or equivalent function residing in the servicecontrol point (2).
 10. User access method to the IN services of anintelligent network comprising a service control point (2) thatcommunicates with at least one group of physical entities (4, 6, 8)designed to provide at least one initial service element, and severalauxiliary platforms (10 _(i)) designed to provide the user withadditional elements that complete the initial service element, saidprocedure being characterised in that it comprises the following stages:real-time sending by the auxiliary platform (10 _(i)) to the servicecontrol point (2) of at least one execution query of service elementsdedicated to the service control point (2); sending by the servicecontrol point (2) in response to said transmitting auxiliary platform(10 _(i)) of data that allows the transmitting auxiliary platform (10_(i)) to execute additional services, wherein, for a given service, thequeries sent to the service control point (2) have the same format,regardless of the transmitting auxiliary platform (10 _(i)), and thedata sent by the service control point (2) to said transmittingauxiliary platform (10 _(i)) has the same format.
 11. User access methodaccording to claim 10, characterised in that the first service elementthat can be executed by the service control point (2) and requested bythe auxiliary platform (10 _(i)) at the service control point using aquery, comprises either a user authentication stage, a service accessauthorisation stage, or a number call stage.